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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 



Introduction 



The present document records the changes to the Internet Engineering Task Force (IETF) RFC 3057 [1]. This RFC 
specifies the ISDN Q.921-User Adaptation Layer (lUA), which is using the services of the Stream Control 
Transmission Protocol (SCTP), the common transport protocol used by all SIGTRAN adaptation layers. 



ETSI 



ETSI TS 102 332 V1.1.1 (2004-06) 



Scope 



The present document specifies the requirements for the ISDN Q.921-User Adaptation Layer (lUA) when used in 
conjunction with the SCTP layer for the transport of Digitals Subscriber Signalling System No. 1 (DSSl) messages over 
the Internet Protocol (IP). The present document endorses and constrains where relevant the lUA defined in 
RFC 3057 [1]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 
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IETF RFC 3057 (2001): "ISDN Q.921-User Adaptation Layer". 



3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 
example 1: text used to clarify abstract rules by applying them literally 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ASPAC ASP Active 

ASPDN ASP Down 

ASPIA ASP Inactive 

ASPM ASP State Maintenance 

ASPSM Application Server Process State Maintenance 

ASPUP ASP Up 

BEAT Heartbeat 

ERR Error 

FAS Facility Associated Signalling 

IP Internet Protocol 

lUA ISDN Q.921-User Adaptation Layer 

NTFY Notify 

QPTM Q.921/Q.931 Boundary Primitives Transport 

RFC Request For Comment 

SCTP Stream Control Transmission Protocol 
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Endorsement notice 



The Elements of the Internet Engineering Task Force Request For Comments RFC 3057 [1] apply with the following 
modifications. 

lUA protocol considerations 

1.1 Scope 

Only Facility Associated Signalling (FAS) shall be supported. 

1.2 Terminology 

The interface id type shall be limited to a 16 bit integer. 

Interface Identifier parameter: only the integer format shall be supported. 

1.3.1 Example - SG to MGC 

The SCTP shall be used as the underlying reliable protocol. 

1.3.3 Signalling Network Architecture 

5*^ paragraph: Stable calls shall not be lost under failure or isolation of a particular ASP. 

1.3.4 ASP Fail-over Model and Terminology 

7* paragraph: In the process of fail-over or fail-back, stable calls shall not be lost. 

1 .5.3 SCTP Stream Management 

The lUA layers shall ensure proper management of SCTP streams. A separate stream shall be used for each D channel. 

1 .5.4 Seamless Network Management Interworking 

If an SCTP association fails, the lUA layer on the ASP side (S12MGC) shall generate Release primitives to take the 
data links out-of-service. 

1.5.5 Congestion Management 

The SCTP layer shall detect congestion and shall control/manage the congestion (e.g. Slow-Start and Congestion 
Avoidance). 

3.1 .2 Message Glasses and Types 
Following message classes shall be supported: 

Management (MGMT) message [lUA] 

3 ASP State Maintenance (ASPM) Messages [lUA] 

4 ASP Traffic Maintenance (ASPTM) Message [lUA] 

5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages (lUA) 

The Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages shall be supported. 
Application Server Process State Maintenance (ASPSM) messages shall be supported. 
Application Server Process Traffic Maintenance (ASPTM) messages shall be supported. 
Management (MGMT) Messages shall be supported. 
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3.1.3 Reserved 

The reserved field shall be set to all "0" s by the sender and ignored by the receiver. 

3.1 .5 Variable Length Parameter Format 

Not more than 3 bytes shall be padded. 

3.2 lUA Message Header 

The interface identifier parameter format shall be Integer. 

Text format is not yet supported. 

The interfaceld can only have values between 1 -> 65 535 (16 bits). 

3.3.1.1 Establish Messages (Request, Indication, Confirmation) 

When the MGC sends an lUA Establish message, the MGC shall start a timer t-establish. 

The MGC shall continue to request the establishment of the data link on a periodic basis until the desired state is 
achieved. 

3.3.1.2 Release Messages (Request, Indication, Confirmation) 

The MGC shall resend the Release Request message, if a response to the Release Request is not received. 

3.3.2.1 ASP Up (ASPUP) 

INFO string shall not be used to carry ASCII characters. 

3.3.2.2 ASP Up Ack 

INFO string shall not be used to carry ASCII characters. 

3.3.2.3 ASP Down (ASPDN) 
INFO string shall not be used to carry ASCII characters. 

3.3.2.4 APS Down Ack 

INFO string shall not be used to carry ASCII characters. 

3.3.2.5 ASP Active (ASPAC) 
The interface identifier shall be coded as Integer. 

3.3.2.7 ASP Inactive (ASPIA) 

The interface identifier shall be coded as Integer. 

3.3.2.9 Heartbeat (BEAT) 

Heartbeat message shall not be used in lUA, as lUA runs over SCTP transport which has its own Heartbeat. 

3.3.3.1 Error (ERR) 

The "Unexpected Message" error shall be sent by an ASP (S12MGC) if it received an QPTM message from an SG 
while it was in the inactive state. The Diagnostic information shall not be used. 
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3.3.3.2 Notify (NTFY) 

The interface identifier shall be coded as Integer. 
The text formatted Interface identifier is not supported. 
The interface id type is limited to a 16 bit integer. 
INFO string shall not be used to carry ASCII characters. 

4.2.1 Layer Management primitives procedures 

5^^ paragraph: The M-NOTIFY indication and M-ERROR indication shall also be sent to Layer Management based on 
local lUA events. 

4.2.2 Receipt of lUA Peer Management messages 

2"'^ paragraph: The M-NOTIFY indication and M-ERROR indication shall also be sent to Layer Management based on 
local lUA events. 

4.3.2 ASPM procedures for primitives 

Last paragraph: At an ASP (S12MGC), the Layer Management shall try to re-establish the SCTP association using 
M-SCTP ESTABLISH request primitive. 

4.3.3.1 ASP Up 

4'^ paragraph: If the ASP does not receive a response from the SG, or an ASP-Down is received, the ASP shall resend 
ASP-Up messages every 2 seconds until it receives an ASP-Up Ack message from the SG. The ASP shall decide to 
reduce the frequency (say to every 5 seconds) if an ASP-Up Ack is not received after a few tries. 

4.3.3.2 ASP Down 

5^^ paragraph: If the ASP does not receive a response from the SG, the ASP shall send ASP-Down messages every 
2 s until it receives a ASP-Down message from the SG or the SCTP association goes down. The ASP shall reduce the 
frequency (say to every 5 s) if an ASP-Down is not received after a few tries. 

4.3.3.7 Heartbeat 

The Heartbeat procedure is not supported by the ASP, as operating is over SCTP. 
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Annex A (informative): 
Bibliography 

• IETF RFC 2960 (2000): "Stream Control Transmission Protocol". 
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